1. Field of the Invention
The invention relates to computer graphics processing, and more particularly to the transfer of graphics data to a rendering subsystem.
2. Related Art
In a typical graphics system, graphics commands and data are created by a host processor in accordance with an application program. This information, known collectively hereinafter as graphics data, must then be transferred to graphics processing components which render an image based on the graphics data. A typical graphics system therefore comprises a host processor connected to a rendering subsystem. When transferring graphics data from a host processor to a rendering subsystem, some graphics systems use system memory as intermediate storage.
This is illustrated in FIG. 1. Graphics system 100 comprises a host processor 105. System memory 110 is connected to host 105. As host 105 creates graphics data 115 in accordance with an application program, graphics data 115 is sent to memory 110 for storage. Host processor 105 is also connected to geometry engine 112. Geometry engine 112 constitutes an initial processing module of the rendering subsystem. At appropriate intervals, host 105 will send a read command 120 to geometry engine 112. Read command 120 serves to instruct the geometry engine 112 to read graphics data 115 from memory 110. This effects the transfer of graphics data 115 from host 105 to geometry engine 112. Geometry engine 112 can then process graphics data 115 to produce output 125. Output 125 is then sent to subsequent modules in the rendering subsystem.
Memory 110 is illustrated in greater detail in FIG. 2. Memory 110 comprises a plurality of graphics buffers. Two of these graphics buffers are illustrated in FIG. 2, a graphics buffer 205 and a graphics buffer 210. Each comprises a series of memory locations. Graphics buffer 205 comprises memory locations 205A through 205n. Likewise, graphics buffer 210 comprises memory locations 210A through 210n. Each graphics buffer receives and stores graphics data from a host processor, pending subsequent access by a geometry engine.
Note that any graphics buffer has a finite size. Any attempt to write beyond the last location in a graphics buffer could result in the loss of graphics data. Hence, in current graphics systems that use buffering, an application that writes data to a graphics buffer must be aware of the size limitation of the graphics buffer. In particular, an application that writes data to a graphics buffer must repeatedly check on the amount of space remaining in a graphics buffer. If insufficient space is available in, say, graphics buffer 205, then the write operation must be redirected to a new buffer, such as graphics buffer 210.
This checking operation slows the transfer of graphics data from a host processor to a geometry engine. The transfer process is illustrated in FIG. 3. A transfer process 300 serves to transfer graphics data from a host processor to a geometry engine by way of graphics buffers in memory. Process 300 begins with a step 305. In a step 310, a value is obtained for the current pointer, representing the address of the next available memory location in a graphics buffer. This must be done before writing graphics data to the graphics buffer. In a step 315, the address of the last memory location in the graphics buffer is obtained. This is the graphics buffer end address. Knowing the graphics buffer end address allows the application to be aware of the location in the graphics buffer beyond which the application must not write. In a step 320 the application obtains the size of the graphics data block that will be produced by the pending graphics command. This value represents the amount of memory that will be required by the pending command.
In a step 325 the value of the current pointer is added to the size of the graphics data block that will be produced by the pending command. This sum is compared to the graphics buffer end address. If the sum is less than the graphics buffer end address, there is sufficient space remaining in the graphics buffer to hold the graphics data of the pending command. Processing would then proceed to step 330, in which the graphics data is written to the graphics buffer. In a step 335 the value of the current pointer is updated. The current pointer now indicates the position of the next available memory address in the graphics buffer. In a step 340 a query is made as to whether there is another command to be processed. If so, the process 300 returns to step 320. In step 320, the size of the memory requirement for the next command is obtained. If there is no additional command indicated in step 340, then the process concludes with a step 345.
If, in step 325, it is determined that there was insufficient memory remaining in the current graphics buffer to contain the graphics data from the pending command, then processing continues at a step 350. In step 350, the contents of the graphics buffer are sent to the rendering subsystem. To send the contents of a graphics buffer to the rendering subsystem, a read command is issued by the host processor to the geometry engine. The geometry engine then reads the buffered graphics data.
In a step 360 a new graphics buffer is allocated to store the graphics data from the pending command, since there was insufficient capacity in the original graphics buffer. In a step 365 the current pointer is reset to point to the first available address in the new graphics buffer. The process then returns to step 315. Here, the graphics buffer end address for the new graphics buffer is obtained.
Process 300, however, can be slow. For every graphics command that must be processed, step 325 must be performed. Therefore, for every command, the amount of memory needed must be compared to the amount of memory available. This requires an arithmetic check before each command can be processed. Moreover, there is a branch in the processing of each command, illustrated as step 325. If the logic of process 300 is implemented in software, step 325 represents a conditional branch instruction. Branching tends to be time consuming in modern computer architectures. Processors typically attempt to anticipate which branch will be chosen, and do a prefetch on the anticipated instructions. An incorrect guess by the processor means that the instructions in the anticipated branch must be discarded, and instructions from the other branch must be loaded. Hence, in light of the branching and arithmetic checking which must be performed for every graphics command, current graphics processing architectures that operate in the manner of process 300 tend to be time consuming.
What is needed, therefore, is a more efficient way to transfer graphics data from a host processor to a rendering subsystem in systems which use memory to buffer graphics data.
The invention provides a method, system, and computer program product for managing the efficient transfer of graphics data to a graphics rendering system. A graphics application program writes graphics data to graphics buffers that are allocated in virtual memory. Each graphics buffer comprises a plurality of memory locations, followed by a sentinel page. While the application is writing graphics data to a graphics buffer, a sentinel page at the end of the graphics buffer may be reached. If so, the operating system recognizes this condition as a graphics buffer page fault. In responding to this fault, the contents of the graphics buffer are transferred to the graphics rendering subsystem. In addition, the graphics data being output by the application is redirected to another graphics buffer.
Features and Advantages
The invention has the feature of incorporating a sentinel page in each graphics buffer. The invention has the additional feature of using the page fault handling process of a virtual memory operating system to facilitate efficient data transfer.
The invention has the advantage of allowing the application program to write graphics data to a graphics buffer without having to check on the availability of memory before each write operation. As a result, the invention has the further advantage of effecting rapid transfer of graphics data to a rendering subsystem.
Further features and advantages of the invention as well as the operation of various embodiments of the present invention are described in detail below with reference to the accompanying drawings.